从商用到开源：DB2迁移至MySQL的最佳实践
身处数据驱动快速变革的时代，数据库系统的选型和架构设计对于整个IT基础架构，甚至企业的发展都起到至关重要的作用。那么今天，如果您的企业需要搭建一套新的应用系统，你会选择什么数据库类型？如果当前的系统不能满足业务需求，面临系统迁移，你又会如何选择？
在2017年初，我们分享过一份国外的报告“开发人员是如何使用数据库的 ”，并且进行了一次调查『中国数据库爱好者的选择和背离』，其中的一些数据展示了用户对于数据库的选择，非常具有参考价值，链接可以直接参考分析报告。
随着互联网+时代的到来，企业的业务发展对IT架构提出了更高的要求，传统的架构往往运维复杂、成本高、不易扩展，在很大程度上制约了企业的快速发展。随着领先互联网企业的开源架构尝试和探索，人们开始逐渐接受并尝试『非IOE』架构和组件，尤其是一些勇于创新的传统行业企业，如金融、保险、证券等，他们正在快速跟上极速变革的技术新时代。
而在数据库领域加速这一过程的，便是以MySQL为代表的开源数据库的应用。MySQL在近几年发展迅速，以其体积小、速度快、成本低，尤其是开放源码等优势受到广大用户的喜爱。
同时，在 DB-Engines 的排名上，Oracle 和 MySQL 两个产品长期霸占了前两名的位置。但根据近几年的增长趋势，MySQL 在这个榜单上超越Oracle数据库是迟早的事，而且这一时点可能很快到来。
近期，云和恩墨为某证券公司进行了从DB2到MySQL数据库系统的迁移论证、验证，对两类数据库展开全方位多角度的对比分析，并根据用户的业务现状进行了相关架构、性能、备份恢复及高可用验证。
在以下的系列文章中，我们将把来自于实践的分析、论证、验证数据分享给大家，从商用到开源，从DB2到MySQL，从传统业务到互联网架构，一切正在发生。
为什么是MySQL不是DB2？
我们知道，IT架构通常由业务架构、数据架构、IT基础架构和应用架构构成，而数据架构则是整个IT架构的中心，企业最核心的资产就是数据。
很多传统的企业比如金融证券等行业的IT软硬件架构都是IBM系列产品，比如IBM小型机/DB2数据库/DS8000高端存储等产品，这种IT架构被业界称为“IOE”架构，其特点是基于向上扩展（Scale Up）技术的高端设备以及围绕它们开发的专有硬件、大型商业数据库和中间件组合。
有人说，DB2在金融证券保险行业有绝对不可替代的优势！
的确，DB2拥有悠久的历史并且被很多人认为是最早使用SQL的数据库产品。主要应用于大型应用系统，具有较好的可伸缩性，可支持从大型机到单用户环境，应用于所有常见的服务器操作系统平台下。然而随着时代的进步，开源产品和技术也已经被证明具备支撑企业核心业务的能力。
时代导向
在移动互联网时代，各组织都在试图构建面向互联网+的安全可控的技术架构，在互联网转型升级压力下，需要对IT系统重构、而数据架构是IT重构的基础和核心。因此上述传统的IOE架构正在逐渐演化为新一代以X86架构、开源应用平台、数据平台等为技术基础的新一代技术架构。
MySQL数据库作为互联网行业IT架构的标配，在长期的实践中积累了大量的高可用、分布式架构和灾备经验。
因此，潮流的改变IT传统架构的演变。越来越多的DB2数据库客户转向开源数据库，而 MySQL 作为当前最火的开源数据库，也常常是受到老DB2用户关注最多的。
政策驱动
将DB2迁移到MySQL并不是一件容易的事，更不可能受单一的时代潮流影响而一蹴而就，对于传统企业来说是一个逐步试水尝试的过程；数据是企业IT架构的核心资产，数据的任何丢失都是难以接受的。而受国家信息安全“自主可控”政策的号召，更加坚定了传统企业作将DB2迁移到MySQL的尝试。比如著名的银监会39号文要求各银行业金融机构对安全可控信息技术的应用以不低于15％的比例逐年增加，直至2019年达到不低于75％的总体占比。
成本驱动
为了稳定运行，很多客户的 DB2 数据库都是运行在全套 IBM 平台中，成本高昂；那么将DB2迁移到以X86架构为主的MySQL数据库当中，数据库运行的底层基础架构的要求大大降低，每年需要给原厂商的商业 License 费用也会随之减少。
随着大数据和云时代的到来，企业的新业务和应用变更非常快，此时，以低成本的方式进行系统扩展和维护便是首要考虑的问题。
自主可控
由于互联网行业的薪资和职业前景吸引了大量技术人才涌入互联网公司从事开发运维等工作，使得原厂技术支持团队人才流失严重，而且服务体制僵化，服务响应流程慢等弊端，导致了服务质量的下降，从而拉低了客户满意度。
将DB2数据库迁移到MySQL，那么可以很大程度降低对原厂服务的依赖性；转而使用“最受欢迎的开源数据库”——MySQL，首先一点是国内MySQL从业人员多，而且深入代码研究的MySQL DBA也不少，第三方服务运维水平也比较高，是现在传统企业拥抱互联网时备受青睐的选择。
社区生态
整个行业DB2技术从业人员相对较少，圈子也在不断缩小，存在人才断崖风险。一方面很多10多年前培养起来的经验丰富的DB2 DBA，或者去了大型甲方单位像大型银行、券商等IT建设投入相对比较大的企业，另一方面很多人才转行到开源领域，或者转行到大数据云计算等行业，社区生态持续收缩。
因此，由于DB2数据库技术人才储备的严重不足以及业内人才梯队断层，导致很多企业招人难，特别是很多中小型企业，社区和产品是相互促进、相互推动，人才必然影响到产品的应用。
推荐使用MySQL的原因
在社区成熟度上，MySQL数据库在开源业界可以说“炙手可热”，便捷灵活，已经广泛被业内看好，而且被Oracle公司接管后，其开发不再像以前典型的开源项目那样开发人员散落世界各地，而是由Oracle公司专门组建了一个MySQL开发团队，团队中有的小组在做集群化软件，有的在做数据库算法，有的在做备份功能，整体上提供了更加成熟的工程模式，未来提升的空间巨大。
从市场占有率看，MySQL排名今年连续攀升，大有赶超数据库龙头“Oracle”的趋势。从如数据库下排名可以看出，市场还是比较青睐MySQL开源数据库的。
全球数据库热度排名中，MySQL稳居第二名直逼第一名。参考链接：https://db-engines.com/en/ranking
在性能上，从我们与PG等其他数据库的benchmark测试结果看，MySQL数据库相对OLTP性能高、简易又灵活、易用性好，比较适用于响应时间灵敏的业务场景。
要注意的事项
当然，在考虑将DB2迁移到MySQL之前，也应该充分认识到MySQL在功能上的一些缺陷。
比如在多表查询方面，MySQL只支持NL JOIN,不支持表的全外连接，也不支持HS JOIN和MG JOIN；MySQL的存储过程和触发器的功能比较弱，甚至不建议在MySQL数据库中对存储过程的使用等。
总之，从功能上，MySQL适合拿来存放数据、不适合做运算场景，实际中大部分互联网公司也只是把它当做数据存储器来使用，把需要的数据取出来然后在应用程序中进行运算，这一点和DB2/Oracle那种商业数据库尽量什么都放到数据库里面的使用风格很不一样。
因此，将DB2迁移到MySQL的话，需要认清MySQL适用于OLTP场景，不建议在OLAP场景中运用；而且必须考虑将原先放在DB2中的某些业务逻辑在迁移到MySQL后，从数据库中剥离出来放到应用中去实现；需要加强对应用架构的管控。
如何实现DB2迁移至MySQL的最佳实践
基于上述的迁移驱动力，你是不是也决定要把你的DB2系统迁移至MySQL了呢？那么如何才能规避迁移中的系列问题呢？这需要我们完全把握两个数据库的特点，各自的优势和不足，在迁移中做合理规划设计。
为此，本系列接下来会包含（但不限于）以下内容，带领大家全面认识DB2迁移至MySQL的实践。
迁移准备
1、DB2与MySQL数据库对比分析。包含：数据库架构对比，数据类型对比，数据库对象对比，SQL对比等。
2、测试。包含DB2与MySQL兼容性测试，MySQL性能测试，MySQL基于OLPT的测试等等。
迁移过程
1、应用设计与改造。
2、MySQL高可用设计与部署
3、MySQL备份与恢复设计
4、迁移中的重点问题和注意事项
迁移优化
1、性能测试
2、系统优化
一场从DB2迁移至MySQL的数据库风暴即将袭来，你准备好了吗？
MySQL vs DB2 Part 1: 体系架构
我们来对比一下DB2与MySQL体系架构有什么不同。
MySQL体系架构
首先我们对图中的组件进行说明。
由连接池组件、管理服务和⼯工具组件、SQL接口组件、查询分析器组件、优化器组件、缓冲组件、插件式存储引擎、物理⽂文件组成。MySQL是独有的插件式体系结构,各个存储引擎有自己的特点。
1、Connectors：指的是不同语言中与SQL的交互
2、ManagementServeices & Utilities： 系统管理和控制工具
3、Connection Pool:连接池：管理缓冲用户连接，线程处理等需要缓存的需求
4、SQL Interface:SQL接口：接受用户的SQL命令，并且返回用户需要查询的结果。比如select from就是调用SQL Interface
5、Parser: 解析器：SQL命令传递到解析器的时候会被解析器验证和解析。解析器是由Lex和YACC实现的，是一个很长的脚本。
a . 将SQL语句分解成数据结构，并将这个结构传递到后续步骤，以后SQL语句的传递和处理就是基于这个结构的
b. 如果在分解构成中遇到错误，那么就说明这个sql语句是不合理的。
6、Optimizer: 查询优化器：SQL语句在查询之前会使用查询优化器对查询进行优化。他使用的是“选取-投影-联接”策略进行查询。
举例： selectuid,name from user where gender = 1;
这个select 查询先根据where 语句进行选取，而不是先将表全部查询出来以后再进行gender过滤，这个select查询先根据uid和name进行属性投影，而不是将属性全部取出以后再进行过滤将这两个查询条件联接起来生成最终查询结果
7、Cache和Buffer： 查询缓存。
如果查询缓存有命中的查询结果，查询语句就可以直接去查询缓存中取数据。
这个缓存机制是由一系列小缓存组成的。比如表缓存，记录缓存，key缓存，权限缓存等
8、Engine ：存储引擎。存储引擎是MySql中具体的与文件打交道的子系统。也是Mysql最具有特色的一个地方。
Mysql的存储引擎是插件式的。它根据MySql AB公司提供的文件访问层的一个抽象接口来定制一种文件访问机制（这种访问机制就叫存储引擎）
现在有很多种存储引擎，各个存储引擎的优势各不一样，最常用的MyISAM,InnoDB,BDB
默认下MySql是使用MyISAM引擎，它查询速度快，有较好的索引优化和数据压缩技术。但是它不支持事务。
InnoDB支持事务，并且提供行级的锁定，应用也相当广泛。
Mysql也支持自己定制存储引擎，甚至一个库中不同的表使用不同的存储引擎，这些都是允许的。
MySQL不是通过多进程来完成其功能的，MySQL只有一个进程，进程里有多个线程。
MySQL的体系架构可划分为以下三个逻辑层：
应用层（Application Layer）
逻辑层（Logical Layer）
物理层（Physical Layer）
（1）应用层（ApplicationLayer）
MySQL管理工具和应用实例（Administrator&Utilities）
主要是连接到MySQL服务器检索、修改或增加数据，有以下常见MySQL管理工具或实用程序。
本地查询接口（Query Interface）
MySQL查询接口主要指mysql脚本，使用mysql工具可以直接与MySQL服务器交互，是日常与MySQL服务器打交道最频繁的工具。
客户端应用接口（Client API）
客户端应用接口主要是使用MySQL服务器对外公布的一些API调用访问数据库，主要有CAPI、PythonAPI以及JavaAPI。
（2）逻辑层（LogicalLayer）
MySQL逻辑层主要是包括以下几个功能：
SQL引擎编译SQL语句
将客户端发送的SQL语句请求通过SQL引擎将SQL语句编译成MySQL服务器内部存取数据的指令的过程，编译过程包括查询解析（QueryParser）、查询检查(Query check)，查询优化（QueryOptimizer）以及查询执行（Query Excution）四个阶段。
事务控制
事务（Transaction）是由一组SQL语句组成的逻辑处理单元，这个逻辑处理单元被原子性地处理，即要么其中的所有SQL语句全部执行成功，要么全部失败，没有第三种可能。那么MySQL是怎么保证事务被原子性地处理呢？这就是Transactionmanagement组件的功能了。当事务全部处理完毕时，通过该组件完成决定commit还是rollback操作。
日志管理
数据库需要将所有对数据变更的操作记录下来，以便当数据库发生crash时做Redo或Undo操作，或者在分布式结构中将操作通过从一个计算节点共享到其他计算节点，这些功能都是通过事务日志来控制的。
MySQL的事务日志管理系统是Recoverymanagement组件，主要功能是持久化事务日志以及当数据库crash时将数据库恢复到crash之前的一致性状态。
存储管理
数据库中操作数据的主要场所是bufferpools，怎么控制数据页和索引页在bufferpool中的状态就是通过storagemanagement完成的，该组件主要还是对Page层面的管理，包括将页读入内存、页的清理等。
值得一提的是，MySQL的逻辑层的上述几个组件功能并不是MySQL特有的，而是普遍适用于DB2/Oracle等常见关系型数据库。
（3）物理层
数据库的物理层主要关注的是数据怎么落地存储以及被有效访问的问题，MySQL的物理层设计比较特殊，MySQL提供了多种存储引擎供用户选择，而且这些存储引擎是可插拔的（Pluggable）,这是区别于业内其他关系型数据库的一个很重要的特征。MySQL数据库为用户提供了20多种可插拔的存储引擎，比较常见的有如下列表所示几种：
如上图的存储引擎中，从功能上比较接近商业数据库功能的是InnoDB存储引擎。从MySQL5.5开始，InnoDB成为MySQL服务器的默认存储引擎；而早在SunMicroSystem被Oracle收购之前的2005年，InnoDB存储引擎就被Oracle收购。
相比较于其他MySQL存储引擎，MySQLInnoDB存储引擎支持以下关键特性：
多版本并发控制（MVCC）
行级锁（Row-level Locking）
外键支持（Foreign key support）
群集索引（Cluster Indexing）
可自由分配的bufferpools
在线数据库备份
以下以InnoDB内部是怎么和磁盘文件交互的详细架构示意图。
如下图是支持访问MySQL数据库服务器的API接口类型，可以通过编写程序调用四种API接口访问MySQL数据库：
JDBC with Connector/J
通过Java程序访问MySQL服务器
.NET with Connector/NET
使用.NET程序访问MySQL服务器
ODBC with Connector/ODBC
Other APIs with C Library
使用基于C语言库的编程语言，比如C/C++语言、Python/PHP/Perl/Ruby语言等访问MySQL数据库。总之，MYSQL支持通过当前最流行的几种主流语言访问。
DB2体系架构
DB2 for LUW进程模型在DB2v9.5之前都是多进程模型，DB2v9.5之后体系架构变更为单进程多线程模型。
DB2是一个C/S结构，客户端可以通过TCP/IP或IPC协议与服务器通信，每当客户端与服务器建立连接之后，会在服务器端产生一个代理线程（db2agent）负责处理来自客户端的所有请求，但是当某一时刻并发请求很多或者连接断开时，重复地产生与销毁代理线程会产生很大的系统开销，所以DB2服务器在启动时创建一个常连接池来避免重复地创建/销毁代理线程，但是如果某一个处理的请求非常大时，如果单个线程去处理效率比较低下，为了提高单个请求的处理能力，与客户端通信的那个代理线程（db2agent）可以从线程池中额外召集几个线程（db2agentp）来共同处理某个请求。
DB2的线程主要分为以下几大类：
常连接池内的线程db2agent和db2agentp：处理客户端请求，比如从bufferpool中取请求的数据，或者将请求拆解放到预取（prefetch）队列中供预取进程（prefetcher）从磁盘取数据使用、或者将一些DML操作记录到日志缓冲区（logbuffer）中等。
通信管理线程db2tcpcm和db2ipccm：负责对来自客户端的连接请求进行安全验证和检查，并与客户端实现三次握手连接。
数据页预取进程db2pfchr/页面清理进程db2pclnr：当请求的数据不在bufferpool中时，需要预取进程db2pfchr通过异步读数据的方式将将所需数据从磁盘读入bufferpool中。
DB2对数据的操纵主要在bufferpool中进行，当插入某些数据或对某些数据做了变更后形成脏页（dirtypage）后，需要使用线程db2pclnr根据一定的机制定期清理bufferpool中的脏页，一方面持久化数据，另一方面给bufferpool腾出更多可置换空间供使用。
日志页读写进程db2loggr/db2loggw：DB2采用的是读日志优先（Read logahead）的策略来持久化数据，即在将insert/delete/update的数据写入磁盘前，必须先将对这些操作的日志从日志缓冲区持久化到磁盘当中，这个操作由db2loggw线程完成。
当需要使用持久化到磁盘的日志恢复或撤销某些操作时，需要从磁盘中将对应的日志读入到日志缓冲区中，此时有db2loggr线程完成。
全局死锁检测线程db2dlock：该线程主要是检测系统死锁防止因为死锁造成的应用不可用。
以下为部分常见DB2管理工具和实例：
该线程主要是检测系统死锁防止因为死锁造成的应用不可用。
以下为部分常见DB2管理工具和实例：
DB2实例命令
相关阅读：
资源下载
关注公众号：数据和云（OraNews）回复关键字获取
‘2017DTC’，2017DTC大会PPT
‘DBALIFE’，“DBA的一天”海报
‘DBA04’，DBA手记4经典篇章电子书
‘INTERNALS’，Oracle RAC PPT
‘122ARCH’，Oracle 12.2体系结构图
‘2017OOW’，Oracle OpenWorld资料
‘PRELECTION’，大讲堂讲师课程资料